@gilles-peskine-arm I have now updated the code workflow now, could you PTAL once?

The major change in the current version of the workflow as compared to the earlier one is that instead of adding the PSA_KEY_USAGE_ENCRYPT attribute to the CMAC key, I have now created a new instance/copy of CMAC key with type AES and the encrypt attribute for allowing us to pass the key to the cipher APIs. This key is created in the _mac_start() API and the key id is stored in the operation context, finally is destroyed when _mac_abort() API is called for the operation context (_mac_finish also calls _mac_abort internally).

Therefore, now we do not need the "hack" of adding the encrypt attribute to the CMAC key thus solving the incorrect key policy issue. Also, even if the CMAC API layer holds a lock on the CMAC key, the cipher API layer can use the key for performing encrypt operations and can hold a lock as well.

Here is the current workflow for an PSA CMAC operation that can internally use an external cipher driver as well:
psa_mac_ (PSA API) -> psa_mac_driver_wrapper_ (driver dispatch) -> mbedtls_psa_mac_ (builtin driver) -> psa_cipher_ (PSA API) -> psa_cipher_driver_wrapper_ (driver dispatch) -> mbedtls_psa_cipher_ (builtin driver).

Having this change would also help disabling MBEDTLS_AES_C when using a custom AES driver layer thus reducing the code size significantly.

Let me know what do you think about this approach!

@gilles-peskine-arm @yanesca Could you PTAL?